REMARKS 

The Examiner rejected claim 1 under 35 U.S.C. § 101 because the claimed invention is 
allegedly directed to non-statutory subject matter. 

The Examiner rejected claims 1, 2, 4, 5, 6, 7, 8 9, 10, 1 1, 12 and 13 under 35 U.S.C. § 
102(e) as allegedly being anticipated by Logue et al. (US 2002/0174341). 

The Examiner rejected claim 3 under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Logue et al. (US 2002/0174341) in view of Atkinson et al. (US 6,367,012). 

Applicant respectfully traverses the § 101, § 102 and § 103 rejections with the following 
arguments. 
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35 U.S.C. § 101 

The Examiner rejected claim 1 under 35 U.S.C. § 101 because the claimed invention is 
allegedly directed to non-statutory subject matter. 

In response, Applicants respectfully contend that claim 1 is not non-statutory 35 U.S.C. § 
101, because claim 1 recites the limitation of "said computer file being attached to an email as an 
email attachment". The computer file of claim 1 is thus useful, tangible, and concrete. 

Based on the preceding arguments, Applicant respectfully requests that the rejection of 
claim 1 under 35 U.S.C. § 101 be withdrawn. 
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35 U.S.C. § 102^ 

The Examiner rejected claims 1, 2, 4, 5, 6, 7 5 8 9, 10, 1 1, 12 and 13 under 35 U.S.C. § 
102(e) as allegedly being anticipated by Logue et al (US 2002/0174341). 

Claim 1 

Applicant respectfully contends that Logue does not anticipate claim 1, because Logue 
does not teach each and every feature of claim 1. For example, Logue does not teach the feature: 
"said computer file being attached to an email as an email attachment". 

In citing Par. 61 of Logue, the Examiner is alleging that a Universal Resource Locator 
(URL) is filename of a file. The file may be web page identified by the URL. However, Logue 
does not teach that the web page identified by the URL is attached to an email as an email 
attachment. 

Based on the preceding arguments, Applicant respectfully maintains that Logue does not 
anticipate claim 1, and that claim 1 is in condition for allowance. 

Claims 2 and 4-9 

Applicant respectfully contends that Logue does not anticipate claim 2, because Logue 
does not teach each and every feature of claim 2. For example, Logue does not teach the feature: 
"computing a digital signature of the computer file using a private key of a sender". 

The Examiner argues that Logue, Par. 61 teaches the preceding feature of claim 1. 

In response, Applicant notes that Logue, Par. 61 teaches that a digital signature 730 is 
appended to a URL 710, but does not teach that the digital signature 730 is a digital signature of 
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the computer file, said computer file being the web page identified by the URL 710. Nor does 
Logue, Par. 61 teach that the digital signature 730 is computed using a private key of a sender. 

Applicant cites Logue, Par. 60 which identifies the following parameters as being input to 
a hashing function 650 to generate a digital signature 660: [a]n application identifier 610 such as a 
host or domain name path, a unique client identifier 620 such as a serial number associated with 
the client 220 or a user ID associated with its user, a secret key 630 that is known to the server 
210 and the client 220, and a random number 640". 

Applicant asserts that none of the aforementioned parameters in Logue, Par. 60 are or 
comprise the computer file which the Examiner alleges be represented by the web page identified 
by the URL Therefore, Logue does not teach "computing a digital signature of the computer file" 
as claimed. 

Applicant asserts that none of the aforementioned parameters in Logue, Par. 60 are or 
comprise a private key of a sender or user. Therefore, Logue does not teach that a private key of a 
sender is used to generate a digital signature as claimed. 

Based on the preceding arguments, Applicant respectfully maintains that Logue does not 
anticipate claim 2, and that claim 2 is in condition for allowance. Since claims 4-9 depend from 
claim 2, Applicant contends that claims 4-9 are likewise in condition for allowance. 

In addition with respect to claim 4, Logue does not teach the feature: "wherein the step of 
computing a digital signature is based on a public-key algorithm". 

The Examiner alleges that Logue teach the preceding feature in Logue, Pars. 57 and 60. 
In response, Applicant asserts that Logue, Pars. 57 and 60 do not teach use of a public key 
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algorithm to compute the digital signature. 

Therefore, Logue does not anticipate claim 4. 

In addition with respect to claim 5 5 Logue does not teach the feature: "wherein the step of 
computing a digital signature includes the steps of: computing a hash value of said computer file; 
and computing a digital signature of the computed hash value using the private, key of the sender". 

The Examiner alleges that Logue teach the preceding feature in Logue, Par. 61. 

In response, Applicant asserts that Logue, Par. 61 does not teach how the digital signature 
is computed. 

Logue, Par. 60 teaches that several parameters are hashed to compute a hashed value such 
that the hashed value is the digital signature. However, does not teach that the computed hashed 
value is further modified (by use of a private key or in any manner) to generate a digital signature, 
since the hashed value is itself the digital signature. Moreover, none of the parameters used to 
compute the hashed value (i.e., the parameters of an application identifier such as a host or 
domain name path, a unique client identifier, a secret key) are or comprise the web page identified 
by the URL, which the Examiner alleges to represent the claimed computer file. 

Therefore, Logue does not anticipate claim 5. 

In addition with respect to claim 7, Logue does not teach the feature: "computing a digital 
signature of the second file using the private key of the sender; and encoding said computed 
digital signature of the second file in a filename of said second file at a predetermined position or 
using delimiters". 
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Therefore, Logue does not anticipate claim 7. 



Claims 10-13 

Applicant respectfully contends that Logue does not anticipate claim 10, because Logue 
does not teach each and every feature of claim 10. 

As a first example of why Logue does not anticipate claim 10, Logue does not teach the 
feature: "recovering an encoded hash value of the computer file by using a public key of a sender 
of the computer file and the extracted authentication information". 

The Examiner alleges that Logue teach the preceding feature in Logue, Par. 62. 

In response, Applicant asserts that Logue, Par. 62 does not teach use of a public key to 
recover an encoded hash value. 

Therefore, Logue does not anticipate claim 10. 

As a second example of why Logue does not anticipate claim 10, Logue does not teach the 
feature: "computing a hash value of said computer file using a hash function used by the sender to 
generate the encoded authentication information". 

The Examiner alleges that Logue teach the preceding feature in Logue, Par. 62. 

In response, Applicant asserts that Logue, Par. 62 does not teach computing a hash value 
of the computer file, and most certainly does not teach computing a hash value of the computer 
file using a hash function used by the sender to generate the encoded authentication information. 

Therefore, Logue does not anticipate claim 10. 
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As a third example of why Logue does not anticipate claim 10, Logue does not teach the 
feature: "comparing the encoded and the computed hash values; and, if the encoded and the 
computed hash values are identical, processing the computer file, else, if the encoded and the 
computed hash values are different, rejecting the computer file". 

The Examiner alleges that Logue teach the preceding feature in Logue, Par. 62. 

In response, Applicant asserts that Logue, Par. 62 does not teach comparing the encoded 
and the computed hash values, and most certainly does not teach that "if the encoded and the 
computed hash values are identical, processing the computer file, else, if the encoded and the 
computed hash values are different, rejecting the computer". 

Therefore, Logue does not anticipate claim 10. 

Based on the preceding arguments, Applicant respectfully maintains that Logue does not 
anticipate claim 10, and that claim 10 is in condition for allowance. Since claims 11-13 depend 
from claim 10, Applicant contends that claims 1 1-13 are likewise in condition for allowance. 

In addition with respect to claim 11, Logue does not teach the feature: "extracting said 
authentication information from the filename of the second file at a predetermined position or 
using delimiters; recovering an encoded hash value of the second file by using the public key of 
the sender and the extracted authentication information of the second file; computing a hash value 
of said second file using a hash function used by the sender to generate the encoded authentication 
information of the second file; comparing the encoded and the computed hash values of the 
second file; and if the encoded and the computed hash of the second file values are identical, 
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processing the second file, else, if the encoded and the computed hash values are different, 
rejecting the second file". 

Therefore, Logue does not anticipate claim 1 1 . 
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35 U.S.C. § 103(a) 

The Examiner rejected claim 3 under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Logue et al. (US 2002/0174341) in view of Atkinson et al (US 6,367,012). 

Since claim 3 depends from claim 2, which Applicants have argued supra to not be 
unpatentable over Logue under 35 U.S.C. § 102(e), Applicants maintain that claims 1 1-12 are 
likewise not unpatentable over Logue in view of Atkinson under 35 U.S.C. § 103(a). 

In addition with respect to claim 3, Logue in view of Atkinson does not disclose the 
feature: "wherein the step of encoding said computed digital signature includes the step of adding 
said computed digital signature in the filename just before a file extension comprised by the 
filename, said file extension being located at an end of the filename". 

The Examiner argues: "As per claim 3, rejected as applied to claim 2. Logue et al. 
discloses: computing a digital signature of the computer file using a private key of a sender; and, 
encoding said computed digital signature in a filename of said computer file at a predetermined 
position or using delimiters. Logue et al. does not explicitly teach adding said computed digital 
signature in the filename just before the file extension, said computed digital signature having a 
fixed size. However, Atkinson et al. discloses: adding said computed digital signature in the 
filename just before the file extension, said computed digital signature having a fixed size 
(Column 6, Lines 50-Column 7, Lines 8)." 

In response, Applicant asserts that Atkinson, col. 6, line 50 - col. 7, line 8 does not 
disclose adding said computed digital signature in the filename just before the file extension. In 
fact Atkinson, col. 6, line 50 - col. 7, line 8 does not even mention a file extension comprised by 
the filename. 
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The Examiner further argues that "it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to use the teachings of Atkinson et aL in conjunction 
with the teachings of Logue et al. as stated by Logue et aL in 0061, where it states the signature 
may be inserted anywhere in the URL." 

In response, Applicant cites Logue, Par. 61 which recites; "Although ... the digital 
signature 730 ... illustrates as being simply appended to the end of the original URL 710, these 
fields may be inserted anywhere in the original URL 710 so long as the inserted location is 
permitted by the governing protocol" (emphasis added). 

Applicant asserts that since the Examiner has not provided evidence that placement of the 
digital signature just before a file extension comprised by the filename is permitted by the 
governing protocol, the Examiner's argument is not persuasive. 

Therefore, the Examiner has not established a prima facie case of obviousness in relation 
to claim 3. 



10/659,111 



16 



CONCLUSION 



Based on the preceding arguments, Applicant respectfully believes that all pending claims 
and the entire application meet the acceptance criteria for allowance and therefore request 
favorable action. If the Examiner believes that anything further would be helpful to place the 
application in better condition for allowance, Applicant invites the Examiner to contact 
Applicant's representative at the telephone number listed below. The Director is hereby 
authorized to charge and/or credit Deposit Account 09-0457. 





Jack P. Friedman 
Registration No. 44,688 



Schmeiser, Olsen & Watts 
22 Century Hill Drive - Suite 302 
Latham, New York 12110 
(518) 220-1850 
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